status/keyboard: Fix execution order when activating source

When commit ce89b15bb123d made the code async, it did not only
delay releasing the keyboard until after the engine has been
updated, but also the following code that updates the current
input source.

One result is that the current source is now initialized later,
which breaks any code that relies on the source being set.

This affects the login screen in particular (which uses different
`InputSourceSettings` than the regular session): It fails to come
up entirely if the OSK is enabled.

To fix the issue, use a .then() callback to release the keyboard,
instead of blocking all following code with await.

Fixes: ce89b15bb1 ("ibusManager: Use async await instead of callbacks")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7912
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3476>

diff --git a/js/ui/status/keyboard.js b/js/ui/status/keyboard.js
index d900d3ed718b7c944f25ec53bdf2deca7b6bf72d..3be8f2cbabbb262486b639c3cdaff1ec63125905 100644 (file)
--- a/js/ui/status/keyboard.js
+++ b/js/ui/status/keyboard.js
@@ -495,7 +495,7 @@ export class InputSourceManager extends Signals.EventEmitter {
         this._changePerWindowSource();
     }
 
-    async activateInputSource(is, interactive) {
+    activateInputSource(is, interactive) {
         // The focus changes during holdKeyboard/releaseKeyboard may trick
         // the client into hiding UI containing the currently focused entry.
         // So holdKeyboard/releaseKeyboard are not called when
@@ -519,9 +519,10 @@ export class InputSourceManager extends Signals.EventEmitter {
         else
             engine = 'xkb:us::eng';
 
-        await this._ibusManager.setEngine(engine);
-        if (!this._reloading)
-            KeyboardManager.releaseKeyboard();
+        this._ibusManager.setEngine(engine).then(() => {
+            if (!this._reloading)
+                KeyboardManager.releaseKeyboard();
+        });
 
         this._currentInputSourceChanged(is);